MRTGトラフィックグラフだけではサーバーの体感速度を判定できない理由
1行要約
MRTGは単位時間あたりのデータ転送量である**スループット(Throughput)を可視化するツールであり、ユーザーが体感する応答速度である遅延時間(Latency / RTT)**を直接測定できないため、性能トラブルシューティングには必ずtracerouteやmtrを併用する必要がある。
1. スループット (Throughput) vs レイテンシ (Latency)
「サーバーが遅い」という問い合わせに対しMRTGグラフが提示されることが多いが、両者は全く異なる物理指標である。
[高速道路の例え]
- Throughput (スループット) : 高速道路の車線数 (8車線 vs 2車線) -> 転送データ総量 (bps)
- Latency (レイテンシ) : 車両の制限速度および渋滞度合 -> パケット往復時間 (ms)| 区分 | Throughput (MRTG) | Latency (traceroute / ping) |
|---|---|---|
| 測定対象 | インターフェースを通過する秒間ビット数 (bps) | パケットが出発地から目的地まで往復する時間 (ms) |
| 体感影響 | 大容量ファイルダウンロード速度に直結 | Webレスポンス、APIコール、SSHターミナル応答性に直結 |
| 相関関係 | トラフィックが少なくても回線混雑時は低速 | トラフィックが多くても余剰帯域があれば高速 |
2. ネットワーク区間遅延診断の標準手法: traceroute & mtr
bash
# Linux: パケットロスと各ホップの遅延をリアルタイム追跡
mtr -rw example.com
# Windows: ホップ別追跡
tracert -d example.com- 特定ホップ以降でRTTが急増、またはパケットロス(Packet Loss)が発生している場合、当該ISPルーターまたはバックボーン区間のボトルネックと特定できる。
3. MRTGグラフが唯一の手がかりとなる例外：帯域飽和 (Bandwidth Saturation)
[帯域飽和時のMRTGパターン: Flat-top Clipping]
Traffic (Mbps)
100M ┌───────────────────────┐ <── インターフェース/QoS上限ライン
│ /───\ /───────────\ │
50M │ / \/ \ │
└─────────────────────────グラフ上端が回線上限値（例：100Mbps）に達して平坦に刈り取られるパターン（Clipping）が観測された場合のみ、バッファオーバーフローによるパケットドロップが発生し、レイテンシが急増している証拠となる。
4. コアチェックポイント (Gotchas)
- 5分平均の盲点: MRTGは通常5分平均で集計されるため、数秒単位の瞬間的スパイク（マイクロバースト）を検知できない場合がある。
- 中間ホップのICMPタイムアウト:
traceroute実行時に* * *が表示されても、単に中継ルーターがセキュリティポリシーでICMP応答をドロップしているだけで障害ではないケースが多い。
投稿日: 2026-07-10 08:56:55更新日: 2026-08-15 13:57:00